@tmilnthorp Waiting for a review on this, then we release a new beta nuget.

Sorry, traveling the past few days. I'll review this tomorrow. There's a couple things I want to compare to.

From an engineering standpoint, I agree 100%. But at what point do you switch from a general use library to an engineering/science specific library?

I would expect 30C - 20C = 10C for "general" use.

If I was using for engineering purpose I'd convert 30/20C to K before doing the subtraction anyways.

A lot of discussion and arguments back and forth were made in #518.

Problem definition:

• "Normal users" will expect 100F - 70F = 30F
• WolframAlpha agrees on this, a widely used scientific tool
• "Engineers" working with temperatures expect 100F - 70F = -429.67 °F = 16.67 K, since you are subtracting two temperatures (levels of energy) and in that context you naturally get a smaller temperature (lower energy level)
• MathCad agrees on this, a widely used scientific tool (I'm not familiar with it)
• The result of temperature addition/subtraction WILL be confusing to one of the two groups of people
• I don't know what is the larger portion of our userbase, can only speculate

My conclusion:
I think either way works and its decision can be justified, but I currently see this approach as slightly better because it is consistent across quantities. Either way will be counter-intuitive to some ratio of our userbase, but I don't know what that ratio is and if this change is worse or better in that regard. I only know that I recognize the consistency as an improvement and I am in the not-temperature-engineering-or-science camp of users.

I'm open to be convinced otherwise, but we need to settle on this. Worst case pull the change out of v4 and think more on it. What do you think @tmilnthorp ?

Update:

I would expect 30C - 20C = 10C for "general" use.
If I was using for engineering purpose I'd convert 30/20C to K before doing the subtraction anyways.

I agree, that was my perception too up until #518. One can also argue that 100F - 70F is simply converting to .DegreesFahrenheit before subtracting. Just as easy. It IS easy, just confusing.

I did not get the look at that much, sorry it's been a bit hectic here.

In any case, I think leaving it as-is gives more flexibility. The average user can still do 30C-20C=10C. I can convert to K for engineering/scientific purposes and do it that way also. I think a broad-use library is just as important as scientific correctness, so why choose?

I think you are missing my point. I believe we are all biased, we all have our own expectations of what Temperature1 - Temperature2 should yield. A delta or a new temperature?
There is no right or wrong, and I would need a metric for how many % of our current users are expecting one over the other to truly decide with confidence.

However, I recognize that adding a special case for Temperature is more complex than treating all quantities alike. That is the reason I favor the new behavior.

I can agree with the argument that before changing the behavior we must first justify it by measuring the expectations in a representative set of our userbase.
But I don't agree with keeping it just because it's more appropriate for a "broad-use" library, we don't know the context in which our users are using this library.

I propose just that, let's revert the change back, close this fix and revisit when we know that a change will indeed improve things. It's pretty clear to me we are not able to fully agree on this just now, and then we shouldn't change anything either.

Reverted #550 in 71bc0a8.